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This  report  describes  the  abstraction  mawhantem  of  a  prototype  systems  implemen¬ 
tation  languages  for  Intel’s  iAPX-432  microprocessor.  The  language  ea a  designed  in 
1977  Bill  Brown  and  myself  (at  Intel)  and  was  implemented  in  Simula  in  1973  and  1979. 
Intel  has  kindly  declared  this  work  non-proprietary,  so  its  publication  is  now  possible 
[3rowoB3].  The  introduction  to  the  language  specification  [PSE.7S]  describes  the 
p reject's  goals: 

1.  “To  provide  an  adequate  tool  for  programming  the  [iAPX-432]. 

2.  “To  provide  experience  in  the  implementation  of  languages  and  systems  for  the 
[iAPX-432]. 

3.  “To  provide  a  first  cut  at  addressing  the  philosophical  language  design  issues  asso¬ 
ciated  with  concurrency,  modularity,  and  protection. 

"The  prototype  language  is  explicitly  designed  as  a  learning  tool  to  establish  the  real 
requirements  far  masting  tbs  above  goals." 

Although  the  prototype  language  is  now  five  yean  aid.  I  think  that  it  has  a  number  of 
unique  characteristics  that  Justify  its  description.  Pull  exploitation  of  the  432’a  facili¬ 
ties  places  many  demands  on  a  language  intended  for  systems  implementation.  The 
432  is  a  capability-based  machine,  with  hardware-enforced  typing  of  ’large*  objects, 
dynamically  instantiated  domains  (l.a.,  packages),  hardware-enforced  information  hid- 
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tog  (seals),  and  bai  deals*  supported,  software-defined  access-rights  (trademarks).  The 
prototype  language's  support  for  thsae  faculties  is  described  below.  The  432  also  pro* 
vidos  a  oar?  dynamic,  message-based  modal  of  cone  arrant  execution:  prototype 
language  factBtiea  to  support  this  modal  are  described  in  a  companion  report 
[UaeL93]. 

The  rest  of  this  report  essentially  reproduces  Section  3.1  and  Chapter  4  of  the  proto¬ 
type  language  specification  [PSIL78].  To  place  this  material  in  context  it  should  be 
sufficient  to  know  that  the  prototype  language  is  an  extensible  da ta-afcs traction 

l 

language  in  the  tradition  of  Alphard.  CLU  and.  MESA.  However,  to  meet  the  require¬ 
ments  of  the  432.  it  is  generally  mere  dynamic  than  these  Languages. 

2.  YiUOD  AMD  OBnCCTS 

Natural  languages  diwHwgnieh  between  common  nouns  and  proper  nouns.  Proper 
nouns  (or  names)  denote  specific  entities  that  exist  (presumably).  Common  nouns 
denote  concepts  or  abstractions,  le.,  classes  of  entities,  or  classes  of  classes,  etc. 
Abstraction*  and  entities  are  compared  and  contrasted  below. 

Both  entities  and  abstractions  have  attributes.  For  instance,  if  'Caesar'  is  a  name 
for  a  specific  entity,  we  can  speak  of  various  attributes  of  this  entity,  such  as  the  age  of 
Caesar  or  the  father  of  Caesar.  Similarly,  if  the  word  s  refers  to  the  complex  number 
1+21  (which  is  an  abstraction),  then  we  can  speak  of  various  attributes  of  this  abstrac¬ 
tion.  such  as  the  real  part  of  * ,  or  the  imaginary  part  of  s. 

Abstractions  and  entities  can  be  contrasted  as  follows.  Entities  are  things  that 
exist:  as  such,  they  can  corns  into  existence  or  go  out  of  existence.  They  have  attri¬ 
butes  that  can  be  changed  in  time  without  altering  the  basic  identity  of  the  entity. 
That  is.  an  entity  remains  that  same  entity  even  though  any  or  ail  of  its  attributes  may 
have  been  changed.  Ibis  includes  the  'internal  attributes/  or  atata,  of  the  entity. 
Since  entities  have  an  identity  which  is  distinct  from  the  attributes  possessed  at  any 
given  point  in  time,  It  is  possible  that  there  can  be  two  entitles  which  have  the 
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attributes,  yet  srs  different  entities.  Such  entities  ara  called  different  instance*  of 


Ths  concept  of  existence  Is  not  applicable  to  abstractions.  Abstractions  arc  time* 
lass.  La.,  it  la  masnlngtaas  to  speak  of  them  coming  into  existence  or  going  out  of 
existence.  Since  an  abstraction  is  completely  defined  by  its  attributes,  changing  its 
attributes  causes  It  to  be  a  different  abstraction.  In  this  sense  abstractions  are 
unmodifiable.  (It  is.  of  course,  possible  to  redefine  the  name  of  an  abstraction.  For 
instance,  the  word  pi'  might  be  redefined  to  refer  to  the  abstraction  17,  but  this 
alteration  does  not  altar  that  number  which  is  ths  ratio  of  a  circle's  circumference  to 
its  diameter.)  The  tact  that  an  abstraction  is  completely  determined  by  its  attributes 
also  implies  that  the  concepts  of  identity  and  instance  are  not  applicable  to  abstrac¬ 
tions. 

Like  natural  languages,  ths  prototype-  language  distinguishes  between  entitles,'  which 
it  calls  objects,  and  abstractions,  which  it  calls  votes*.  The  programmer  generally 
dealt  with  values  (such  as  numbers  or  c  haracters),  except  where  updating:,  state  infor¬ 
mation,  or  sharing  are  involved,  in  which  cases  objects  are  required.  Hie  naming  of 
objects  and  values  is  discussed  in  Section  3. 

&  SPSanCATEOHS  AMD  BDIOOIGS 

As  was  discussed  in  Section  2,  ths  prototype  language  Is  capable  of  describing  both 
values  (abstractions)  and  objects  (entities).  To  facilitate  such  description,  values  and 
objects  can  be  denoted  by  words  (or  names).  These  correspond  to  the  common  and 
proper  nouns  of  natural  languages.  This  chapter  describes  how  these  words  ara 
defined,  a  process  called  Mndtnp.  Values  can  also  be  described  by  'denotations,'  which 
ara  self-defining  names  for  values.  For  example,  'Z  Is  a  denotation  for  2;  it  does  not 
have  to  be  explicitly  defined  Hals  chapter  discusses  the  denotations  for  non-primitive 
values. 
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ft  has  bats  shown  that  both  objects  and  values  hm  attributes.  These  attributes  an 
mmUj  a-nd.  but  can  bo  denoted  by  indexes.  aa  ia  tho  com  with  array*.  (Ultimately 
aU  nminmm  coesldsred  attribute  name*,  aloe*  tho  namea  of  variables,  procedure*, 
ata.  an  attributaa  of  tho  environment.)  Thia  chapter  diacuasea  the  ways  in  which 
nemoa  an  aaaoeiated  with  values  and  object!  ('binding'),  the  ways  in  which  one  can 
reetrict  the  claaa  of  value*  or  objects  to  which  a  name  will  later  be  bound 
('specification'),  the  ways  of  specifying  classes  of  values  and  objects  ('types'),  the  ways 
in  which  values  can  be  constructed  from  men  primitive  values  and  objects  ('compo¬ 
site'  values),  and  the  rules  governing  the  context  in  which  names  an  known  ('scoping'). 


specification:  bind-mode  spec. 


[i 


H  specification 

—mod*  bound-part 
label -binding 


bind— mode:  volatility  . 

*  volatility:  [“£*]. 
op:  opacification  ;  . 
bd:  binding  ;  . 

Figure  1.  Specification  and  Binding  Syntax 

Specification: 

varac  real: 

proa  fee(n:  int)  •>  ink 


Binding: 
verxr  real*  0: 
pi  *  3.14150: 
preefac(n:  lot)  ->  1st  is 
if  n*0  then  return  1; 
else  return  n*fac(n-l): 
end  If: 
end  fee; 


figure  2.  Specification  and  Binding  Examples 

The  concept  of  a  binding  is  of  central  importance  in  the  prototype  language.  A  bind* 


log  if  Um  formalization  of  thf  a>tnntiio|ui|i  process  of  dsAmng  &  word  or  nanu.  In 
thii  process  a  "**"«*«""  noun  la  associated  with  a  particular  concept,  or  a  proper  name 
i*  assort  atsd  with  a  particular  entity.  In  the  same  way  a  binding  associate*  a  name 
with  a  particular  value  or  object  (the  language  does  not  distinguish  between  common 
nouns  and  proper  names).  The  »*»*«  is  said  to  be  bound  to  the  value  of  object.  For 
instance. 

cooat  pi;  rsai  *  3.1*159; 

binds  the  mum  'pi'  to  the  value  denoted  '3.14159.'  The  binding  can  be  paraphrased  "pi 
is  defined  to  be  the  real  number  3.14159."  The  word  const  means  that  this  definition  is 
constant,  or  permanent,  within  the  scope  of  the  definition. 

It  is  often  useful  to  have  a  nunn  that  at  various  limes  can  refer  to  different 
members  of  a  class  of  values  or  objects.  An  example  of  such  a  'variable'  binding  is: 

varx:  reel »  3.14159; 

This  could  be  paraphrased  ”x  currently  stands  fer  -he  real  number  3.14159."  The  bind¬ 
ing  is  variable  because  tbs  name  'x'  can  be  rebound  to  another  value  of  the  same  type 
(Le..  reel)  anywhere  within  the  scope  of  'x.  This  s  accomplished  with  an  assignment 
operation.  Formally,  variables  are  just  changeable  attributes  of  a  firm  adject  (Section 
5)  representing  the  current  environment.  As  a  matter  of  convenience,  the  type  can  be 
omitted  when  it  can  be  deduced  from  the  bound  value.  Also,  const  is  assumed  if  it  is 
omitted. 

For  the  following  discussion  an  understanding  of  Algol  scope  rules  will  suffice.  It  will 
usually  be  the  case,  as  in  Algol,  that  the  current  environment  of  known  names  Is  com¬ 
posed  of  those  defined  in  the  current  (local)  program  unit  together  with  those  con¬ 
tained  in  outer  (noo-iocai)  program  units.  In  Algol,  if  the  current  program  unit  defines 
a  name  that  already  la  defined  in  the  non-local  environment,  then  the  new  name  super¬ 
sedes  the  old.  Such  implicit  redefinition  is  illegal  in  the  prototype  language,  since  it  is 
a  frequent  source  of  errors.  An  name  con  be  redefined  in  an  inner  scope,  but  the 


programmer  most  make  his  intention  explicit,  by  writing 


For  example: 


Mw  r  nail 


let  redefine  varx:  lot*  1; 


In  the  prototype  languaga,  all  bindings  establishad  within  a  given  scope  are  inter* 
prated  to  be  mutually  recursive.  This  means  that  the  bodies  on  the  right  of  the  bind¬ 
ings  ‘see’  the  names  on  the  left.  This  allows  simply  recursive  functions  to  be  defined  in 
the  obvious  way.  e.g.. 

proa  fac(n.‘int)  =  (n=0  =>  1 1  n*fac(n-l)); 

This  rule  also  allows  sets  of  mutually  recursive  procedures  to  be  defined,  e.g., 

proc  f  *  ...  g  ... 
proc  g  =  ...  f  ... 

Sometimes  is  is  useful  to  redefine  a  name  in  terms  of  its  previous  (more  global)  mean¬ 
ing.  For  this  purpose  the  mutually  recursive  Interpretation  can  be  suppressed  by  writ¬ 
ing  oonrec.  This  means  that  the  right- band-side  of  the  binding  will  'see'  only  the  non¬ 
local  environment.  For  instance,  it  if  were  desired  to  redefine  'Sin'  so  that  it  worked  in 
terms  of  radians  rather  than  degrees,  this  could  be  done  by 

nonrac  pros  Stn(theta:rml)  a  Sln(theta/I80*pi); 

\  binding  defines  the  name  on  the  left  to  be  the  current  value  or  object  described  by 
the  expression  on  its  right.  Thus,  the  binding  'const  w  »  Sam. car. weight;’  can  be  para¬ 
phrased  "define  w  to  be  the  current  weight  of  Sam's  car."  The  fact  that  the  car's 
weight  may  latrr  change  will  not  effect  the  value  of  w.  Occasionally  it  is  desirable  to 
introduce  a  name  to  stand  for  an  attribute's  value  at  ail  times.  Thus,  it  might  be  desir¬ 
able  to  define  ’cw*  to  mean  the  weight  of  Sam’s  car,  at  any  time.  This  can  be  done  with 


>h«  MwiMng' 


Nan*  cw  *  Sam.  car.  weight; 

This  La  an  example  of  a  'name  definition'  Altar  this  definition  'cW  can  be  used  any¬ 
where  ‘Samcar.  weight’  could  have  bean  used.  For  example,  the  weight  of  the  car  can 
be  changed  by  'aw 4015;'. 


A  specification  is  essentially  a  binding  without  an  initial  value.  It  is  used  to  restrict 
the  set  of  values  to  which  the  name  will  be  later  bound  (say  by  extension). 
Specifications  usually  occur  in  class-denotations  (section  4).  Examples  of 
specifications  will  be  found  throughout  this  report. 


[  class -dsn 

i  record  -ty, pm  —dsn 

*■-*"  !  SSESM 

procedural  -type  -dsn 
;  sny[tientf/ler] 


clam-dan:  deem  [gtmus  ]  Sp*  ood  [dam] 
germs  type  with . 


record-fype-den:  i-ecord  Bd  *  end  [record]  . 
-union -type -dsn:  union  3p  *  end  [union] . 

enuro-lgpe-den:  ennm  j*  |  ) 


Figure  3.  Syntax  of  Types 


The  concept  of  a  type  in  the  prototype  language  is  very  similar  to  a  Pascal  type  or 
an  Algol  66  mode.  The  differences  will  be  discussed  later.  The  type  denotations  (type- 
dsn)  are  the  primitives  which,  with  the  type  operators,  are  used  to  construct  type- 
expressions.  Throughout  this  document,  the  non-terminal  type  is  used  to  denote  such 
a  type-expression.  As  in  Pascal  and  Algol  68  a  type  denotes  a  set  of  values  or  objects 
that  share  certain  attributes  and  operators.  The  specific  sets  are  described  below. 

Perhaps  the  moat  familiar  type  denotation  is  the  record-type  denotation.  A  record 
(n-tupl,  structure)  denotes  a  unordered  heterogeneous  data  structure.  Sea  the  exam- 


lalnfc  RLreai: 


bon.  neutj 
violet,  Indigo,  blue,  groan, 
yellow,  orange,  rod) 


proe  moro  -> 
net; 

proe  next  -> 


Figaro  4.  Examples  of  Types 

pU  in  Figure  4.  Records  in  the  prototype  language  preside  facilities  now  quite  com¬ 
mon,  such  as  initial  (default)  values  for  Helds  and  position-independent  initialization  of 
fields.  These  facilities  are  justified  and  described  in  [MacL75],  Chapter  6. 


Since  there  are  no  references'  in  the  prototype  language,  records  can  be  directly 
recursive  in  definition.  For  example,  the  following  is  a  definition  of  LiSP-styte  lists: 


ceil  *  union  atom:  string; 
nonnull:  list; 
null:  |J; 

end 


list  a  record  car  cell,  cdr  cell:  end: 

If  L  is  of  type  oell,  then  we  can  discriminate  its  variants  by  expressions  like  'L  is  atom' 
or  by  a  variant  earn  statement  (see  [Hoere73]). 

In  natural  languages,  a  elan  (concept,  abstraction)  is  defined  by  stating  the  genus 
to  which  the  members  of  tbs  dsn  belong  and  the  attributes,  attribute  ranges  or  attri¬ 
bute  values  that  tH«Mwg»oeh  tbs  members  of  the  clan  from  the  other  members  of  the 
genus.  This  method  of  definition  is  captured  by  the  class  construct  in  tbs  prototype 
language.  Readers  acquainted  with  the  Simula  or  Smalltalk  elan  should  be  on  familiar 


ground,  consider  the  class  binding 


as  ctanj  withrf  and; 

The  class  being  defined  Is  *n.‘  the  genu*  Is  g  and  the  diffrrtniia  are  d.  The  binding  can 
be  paraphrased  "define  ‘a'  to  be  the  class  of  ail  g  such  that  d."  The  effect  of  the 
definition  is  to  attach  a  name  to  all  values  or  objects  which  are  in  the  genus  and  satisfy 
the  differentia  (which  are  specifications).  Each  specification  associates  a  set  of  possi¬ 
ble  values  with  an  attribute  name.  If  the  attribute  already  exists  as  an  attribute  of  the 
genus,  then  the  respecification  must  be  compatible  with  the  old  specification,  i.e.,  the 
new  set  of  values  must  be  compatible  with  (La.,  be  a  subset  of)  the  old  set.  An  attri¬ 
bute  is  required  to  have  a  particular  value  by  specifying  a  singleton  set  of  value. 

An  example  may  clarify  these  ideas.  Suppose  class  'animal'  had  already  been 
defined.  The  following  additional  classes  are  defined: 

bird  a  daaa  animal  with  wingspan:  ini;  end: 

parrot  =  daae  bird  with 

color:  ennm  jgryen.  blue,  grey,  brown,  mixed j; 

name:  string; 
end; 


green-parrot  =  dees  parrot  with 
color  Igreenj; 

and; 


large_parrot  =  dee e  parrot  with 

wingspan:  |50  to  lOOQj; 

These  bindings  define  a  hierarchy  of  abstractions,  each  being  a  rnfinrmmt  of  a 
proceeding  abstraction  Thus,  a  'bird'  is  defined  to  be  any  animal  with  a  wing  span,  a 


parrot  la  defined  to  be  a  bird  with  ana  of  tho  specified  colors  sad  a  name,  a  green,  par¬ 
rot  is  defined  to  be  a  parrot  with  color  groan,  and  a  large  parrot  is  defined  to  be  a  par¬ 
rot  with  a  wingspan  greater  than  SO  cm. 

A  more  useful  class  than  parrots  is  defined  by  the  binding: 

file  »  class 

proc  reset; 

proc  more  ->  Boolean: 
proc  next  ->  char, 
proc  put  (c:char); 
and  file: 

This  defines  a  'file*  to  be  any  object  or  value  that  has  ‘reset'  ‘more’  'next'  and  ‘put’ 
attributes  as  specified.  A  procedure  to  copy  one  file  to  another  could  be  defined: 

proc  copy  (fl:flle.  (•  to  •)  f2:flle)  is 
fl.  reset; 

while  fl.more  repeat 
f2.put  (fl.next); 

and  copy. 

This  procedure  will  work  on  any  values  or  objects  that  have  the  specified  attributes. 
For  instance,  they  might  be  disk  or  tape  files  or  arrays  or  sequences  of  characters  in 
memory. 

Sometimes  the  only  attributes  two  or  more  types  share  is  the  fact  that  they  partici¬ 
pate  in  a  collection  of  operations  or  relations.  To  allow  this  the  prototype  language 
provides  for  the  denotation  of  types  which  are  the  discriminated  union  of  other  types. 
(See  the  preceding  definition  of  'cell.') 
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formrden:  (arm  [extension]  form-body  and  [farm] . 
exp  with. 

farm-body:  [  [pobUo]  Bd  }* . 

fleam  CL  Syntax  of  Forms 

&  >0—8 

Forms  provide  a  mechanism  for  directly  constructing  values  by  defining  their  attri¬ 
butes  in  terms  of  other  values  and  objects.  A  form  is  a  collection  of  bindings,  which 
comprise  the  attributes  of  the  value.  The  attributes  may  be  procedural,  data,  type,  or 
other  values  or  objects.  Unliks  classes,  the  attributes  of  a  form  are  divided  into  two 
groups,  the  private  attributes  and  the  public  attributes.  The  public  attributes  are 
signified  by  the  word  public  proceeding  the  bindings.  These  attributes  can  be  made 
visible  outside  the  form  through  the  with  ntatement  (described  later).  The  names  and 

types  of  the  public  attributes  deUimine  i.fce  type  of  the  form. 

* 

An  object  can  be  constructed  according  to  a  form  by  proceeding  the  form  with  obj. 
This  is  the  primary  mechanism  “or  directly  constructing  objects  from  other  values  and 
objects.  Examples  will  be  seen  beiew. 

One  common  use  of  form  values  is  to  define  'libraries'  of  related  procedures,  con¬ 
stants  and  types.  For  instance,  a  library  for  complex  arithmetic  could  be  defined  as  in 
Figure  7.  When  such  a  library  has  been  defined,  it  can  be  used  as  follows: 

with  CampArith  do 

let  vsr  r  complex: 

Let  vsr  a.  b,  c:  complex; 


if  z  =  L  then  z:=  a  •  b  /  c; 


amt 
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rho  *  (x2  +  y2)t(l/2); 
theta  *  arctan(y/x); 


Figure  8.  Ewmpu  of  Farm 

Stacs  a  library  ia  just  a  aat  of  bindings  between  namaa  and  objects  or  values,  and  aa 
such  baa  no  memory’  (i.a.,  state  information)  it  ia  appropriate  that  it  be  defined  as  a 
form  value  (aa  oppoaed  to  a  form  objaetj.  An  example  of  a  structure  winch  does  haws 
memory,  and  tbua  should  be  implemented  aa  a  form-object,  ia  a  stack.  A  particular 
massage  stack,  'Msgstk'  can  be  defined  by  a  binding  such  aa  that  in  Figure  8  (the 
sequence  operations  are  built  in  and  the  type  message  is  assumed  to  have  been 
defined).  It  ia  now  possible  to  push  massages  onto  and  pop  messages  off  of  MsgstJc 


let  verm,  n;  massage; 


Msgs  tic.  push  (m); 


if  not  Msgstk. empty  then  n :  =  Msgstkpop;  out 

The  combined  powers  of  classes  and  forma  provide  a  very  useful  facility,  namely,  tbs 
ability  to  have  multiple  Implementations  at  a  single  abstract  type.  As  an  example,  the 
abstract  type  message  stack'  will  be  defined.  One  form  will  use  tbs  sequence  imple¬ 
mentation  used  in  tba  previous  example,  the  other  will  use  finite  arrays.  The  abstract 
concept  of  a  message  stack  is  defined  by  the  following  class: 

message-stack  *  mstk  object 
where  mstk  *  dees 


pros  push  (m:  message); 
pros  pop  ->  message; 
proa  empty  ->  Boolean; 


CompArtth  *  form 

pottle  complex  *  record  re:  net;  im:  reel:  cod; 
pottle  nonet  i  *  complex  (0,1); 
pottftn  proe  6  (x:  complex)  +  (y:  complex)  * 
complex  (rre  +>  y.re,  rim  y  im); 
pottle  proe  8  (x:  complex)  *  (y:  complex)  a 
complex  (rre  -  y.re,  rim  ■  y.im); 
pottle  proa  7  (r  complex)  *  (jr  complex)  = 
complex  (rre  *  y.re  -  rim  *  y.im. 
rre  •  y.im  +  rim  •  y.re); 


figure  7.  Form  far  Complex  Arithmetic 

A  procedure  ‘sogjaastack*  (for  '3e queue a_type  message  stack)  is  aow  defined  which, 
returns  a  new  sequence-based  stack  object.  The  actual  definition  of  these  c-bjects  is 
the  same  as  Msgstk.  see  Figure  9. 

An  alternative  implementation  of  'message  stack*  is  provided  by  the  procedure 
arr  mstark*  (for  'array- type'  message  stack)  which  returns  a  new  arr  ly-bas ed  stack 
object  of  a  given  size.  See  Figure  10.  Note  that  a  form-returning  proc<  dure  has  been 
used  to  get  the  effect  of  ‘generic’  forms;  unlike  in  Ada,  a  separate  generic  mechanism 
is  not  required  in  the  prototype  language.  Note  also  that  'arr_mstack'!  have  an  addi¬ 
tional  attribute,  'full'  which  inquires  whether  the  stack  is  fuiL  This  attribute  makes  no 
sense  for  ’sag  mntack'a  since  they  are  unbounded  in  size.  Regardless  of  this  extra 
attribute,  both  ‘aeq  janstack's  and  '  arr_ni5tack's  are  of  type  massaga-stack.'  This  is 
because  they  both  satisfy  the  definition  of  messages  tack,'  Le.,  they  have  the  required 
attributes  with  the  given  specifications. 

The  following  program  fragment  declares  several  stacks  using  these  procedures 
(including  Msgstk)  and.  declares  a  ’stack  variable,'  CurrentStacic  which  at  various 
times  will  refer  to  either  sequence  or  array  based  stacks. 


Magstk  *  atf  form 
nrit 


lot  top  ■  st-Arst, 
at :»  atAul: 
itop; 


(st  «  []); 


Dgon  1  A  Massage  Stack  Form-Object 
lot  Magatk  *  saq-mataclc 

also  Ansatk  *  arr-matack  (SO); 

also  ear  Currants  tack:  nminaga  jtaclr 


CurrantStack  :*  Magatk; 

Currants  tack  :*  anuastack  (100);  X  A  now  array  stack 


If  CurrantStack  haa  full  than 
B  not  CurrentStack.full  titan 
CurrantStack.  push  (m); 


Tha  last  atatamant  uaaa  tha  haa  operation  to  datarmlna  if  tha  stack  now  raferrad  to  by 
CurrantStack  baa  a  'full'  attribute. 

Tha  satanston  part  of  a  form  allows  ona  form  to  ba  craatad  which  is  an  extension  of 
another  form.  That  Is.  a  now  form  can  bo  craatad  by  adding  or  respecifying  attributes 
at  an  existing  form,  which  is  similar  to  tha  Simula  and  Smalltalk  subclass  mechanisms. 
It  is  hart  illustrated  by  an  axampla  adapted  from  tha  DEC-10  Simula  manual.  Consider 
a  form  that  manipulates  vectors  (figure  ll).  Note  that  tha  procedure  'norm'  is  not 
bound,  it  is  only  specified,  even  though  it  is  used  in  tha  normalize’  procedure.  A 
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pubic  proa  pop  ii 
let  top  *  st  .first; 
it  :=  stftnsi; 


pa  bile  prae  empty  =  (st=[J); 
sad  fans: 

fleam  0.  Sequence-type  Message  Stacks 

specific  ‘norm'  procedure  can  be  bound  in  an  extension  of  ‘row.’  To  continue  the  exam¬ 
ple.  two  extensions  of  ‘row,’  with  different  ‘norm'  procedures,  are  defined;  see  Figure 
12.  Thus  'rowl. normalize;'  will  normalize  its  array  using  the  first  'norm'  and 
raw2.norrialize;‘  will  normalize  its  array  using  the  second  ’norm.’ 

&  AjTHUttTE  COHPOfSHGM 

The  attribute  composition  operators  allow  the  manipulation  of  the  attributes  of 
values  and  objects.  The  expression 

x  excluding  (id!,  id, . id,) 

is  ihe  same  object  or  value  aa  *.  except  that  the  attributes  idj,  id*  ....  id*  are  no 
longer  available;  they  have  essentially  been  made  private.  For  instance,  if  it  were 
desired  to  pass  SymTab  to  a  procedure  P  in  such  a  way  that  P  could  not  enter  anything 
into  SymTab,  then  an  approapriate  invocation  would  be: 

P(SymTab  excluding  (enter) ); 

Sometimes  it  is  easier  to  state  tbs  attributes  that  are  to  be  kept  then  to  state  those 
that  are  to  be  deleted.  This  the  purpose  of  the  including  operator.  The  expression: 

x  tnehwing  (idt,  id,, - id,) 

is  the  same  object  or  value  as  z,  except  that  all  attributes  other  than  idt,  id,,  ....  id, 
are  no  longer  available;  l.e.,  the  only  public  attributes  are  idt,  id,,  ....  id*.  For 
instance,  if  center  is  a  two-dimensional  position  (with  both  Cartesian  and  polar 


pros  arr-xnstack  (Hu:  hat)  * 
ohjfona 

witmH«a|«Kny(l  toslsej; 
vert:  (OtoslssJ  *  0; 
pubtte  pm  push  (a:  msssaga)  is 
if  full  than  error  sad 

t  :*  t  4-  1; 

8t[t]  :*  nu 

public  pros  pop  ->  message  is 
if  empty  then  error,  end 
t  :*  t  -  1; 
return  st[t  +  1]; 

puMte  pros  empty  =  (t  =  0); 
public  proo  full  =  (t  =  adze); 

end  fans; 

figure  101  Array-type  Message  Stacks 
coordinates),  then  a  strictly  polar  version  of  the  value  Is: 


center  inchxtng  (rho,  theta) 

The  last  attribute  composition  operator  is  merge.  If  x  and  y  are  objects  or  values, 
thanx  merge  y  is  a  value  with  all  of  the  attributes  of  both*  and  y.  More  precisely,  for 
every  attribute  of  either  x  or  y,  there  is  an  attribute  in  x  merge  y  with  the  same  name 
as  that  attribute  in  x  or  y.  Of  course,  x  merge  y  Is  defined  only  if  the  identifiers  for 
the  attributes  of  x  and  y  are  disjoint.  The  merge  operator  is  usually  used  in  conjunc¬ 
tion  with  the  with  statement.  For  example,  if  Math-Lib  and  Plot-Lib  are  two  forms  con¬ 
taining  libraries  of  procedures,  then  all  the  attributes  of  both  can  be  made  available 
by: 


with  Math-Lib  merge  Plot-Lib  do 


If  the  only  procedures  needed  from  Uh  are  Sin  and  Cos,  then  the  following  would 
be  better. 

utth  Plot-Lib 


Math-Lib 


(Shi,  Cos)  do 


raw  *  obj  farm 

pabUenrA:  nalunji 
public  proo  norm  *>  mol: 
pufcttn  proo  normalise  la 
Mwrtmflrm: 

If  t  OOthan 
t  :*  1/t; 

far  name  ai  in  A  repeat 

ai  :*  ai  *t; 


Figure  11.  Form  Object  to  Manipulate  Victors 


end  with; 


7.  TRADOUBES  AND  SEALS 
7.1  Dtwdtanwfes 

A a  discussed  in.  section  4.  a  sat  of  named  (or  numbered)  attributes  and  the  set  of 
values  or  objects  to  which  they  may  be  bound  determine  a  class.  In  that  section  the 
class  file  was  defined: 

file  *  dees 
pros  reset: 

proo  more  ->  Bn  dean; 
proo  next  ->  char: 
pros  put  (c:  char); 

This  defines  a  'file'  to  be  any  object  or  value  with  attributes  'reset,'  'more,'  'next'  and 
'put'  of  the  types  specified.  This  Is  a  powerful  and  flexible  facility.  It  allows  the 
tUemtinn  of  procedures  such  as  Copy  (defined  In  Section  4)  that  copies  any  ‘fils'  to  any 
other  ’file.’  There  may  be  many  implementations  of  flies,  e.g.,  disk-flies,  character 
sequences,  and  character  generators,  as  long  as  they  define  the  stated  attributes. 
There  is,  of  course,  no  guarantee  that  the  attributes  of  a  particular  file  implement  the 
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row!  *  obj  farm  row  with 
paHtopmannia 
MwtmlaO; 
far  ai  in  A  repeat 

t  :*  t  + 


ro»2  *  afcj  farm  row  with 
pafctto  pra  norm  la 
Mnri;  nil*  0; 
lot  wort:  root 
for  al  in  A  npwt 
t  :*  ate  si: 

if  t>*  than  s:*t;  ad 

return  s; 
and  norm: 

Figure  12.  Extensions  of  Row 

functions  implied  by  their  English  nemos;  it  is  oily  required  that  the  types  match.  This 
is  sometimes  unsatisfactory.  In  particular  there  will  be  circumstances  in  which  a  Die 
(far  example)  is  required  which  has  been  formally  or  informally  verified  to  satisfy  csr- 
tain  properties.  For  instance,  we  would  expect  that  writing  a  file,  resetting  it.  and  then 
reading  it  would  produce  the  original  data.  Since  the  prototype  language  includes  no 
direct  support  for  verification,  soma  other  means  must  be  provided  for  this  protection 
This  is  the  tradimark.  It  is  essentially  the  same  as  the  transparent  seat  described  in 
[HarrisTO], 


Anyone  can  construct  'files.'  The  danger  Is  that,  although  they  must  satisfy  the 
class  definition  the  Alas  may  be  defective  in  some  subtle  way  (e.g.,  are  write-only)  or 
are  otherwise  unacceptable.  In  the  real  world  the  consumer  can  protect  himself  by 
obtaining  his  files  from  a  'reliable  source,'  l.e.,  a  source  that  ha  is  confident  will  provide 
him  with  an  acceptable  '(Be.’  hi  the  real  world  there  are  two  ways  a  consumer  can 
ensure  that  a  given  'file'  comes  from  this  reliable  source: 


1.  Request  It  directly  form  the  reliable  source. 
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Syntax. 

artr— tapriMion:  attr-trrm  marge  •  •  *  . 
atfr-tarm:  prfafnary|g^^«|  (id,...)  . 

Bwmpl— 

Math-lib  mefge  Plot-Lib 
SymTab  encfading  (enter) 
center  inducing  (r ho,  theta) 

Figure  ia  Syntax  of  Attribute  Composition 
2.  Require  that  it  bear  the  ’trademark'  of  the  reliable  source. 

Case  (1)  is  straight-forward  and  requires  no  further  discussion  The  trademark  which 
an  object  or  value  bears  is  an  attribute,  just  is,  for  instance  that  objects's  or  value's 
color.  The  difference  ia  that  the  generation  and  attaching  of  trademarks  is  3trictly 
controlled.  In  the  real  world  this  is  a  function,  of  the  government  (since  a  trademark  ia 
private  property);  in  a  computer  systim  it  is  administered  by  the  programming 
language  and  enforced  by  the  operating-system  and  hardware. 

In  the  prototype  language,  trademark.)  are  declared  only  in  forms  and  classes.  Such 
a  declaration  takes  the  form: 

trademark  Acme; 

which  declare*  the  trademark  'Acme.'  This  has  two  effects:  within  the  farm  in  which 
the  declaration  appears,  an  expression  such  as  x  qpa  Acme  returns  a  version  of  x  with 
the  trademark  Acme.  Outside  of  the  form  of  declaration  the  trademark's  name  can  be 
seen  (like  other  publics  of  the  form),  but  not  used  for  applying  trademarks.  An  expres¬ 
sion  such  as 

if  y  is  Acme  than... 

wtU  determine  whether  y  has  the  Acme  trademark.  A  file  bearing  the  Acme  trademark 
is  denoted  by  'Acme  k  Ole,'  using  k,  the  type-intersection  operator.  Thus,  if  it  wars 
desired  that  Copy  only  work  on  Acme  flies,  its  procedure  head  could  be  written: 

pane  Copy  ( fl:  Acme  It  file,  f2:  Acme  k  file)  ia  ... 
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Syntax. 

labml -binding:  labml-variaty  id— Hat  . 


taM  vmriaty: 


;  standard; 
[atom,  nuti; 


ngm  14.  Syntax  tor  Trademark!  and  Seals 
Of  count  it  is  potable  to  ban  mart  than  one  trademark  on  a  value  or  object,  or  to  use 

the  same  trademark  on  several  classes  of  values  or  objects.  (Acme  may  also  make 
very  fine  stacks!) 


The  example  in  Figure  15.  which  allows  the  use  of  both  degrees  and  radians,  is  a 
non-traditlonal  use  of  trademarks  (i.e.,  units;.  Note  that  we  have  also  overloaded  the 
assignment  operation:  this  defines  coercions  between  radians  and  degrees. 


DoubleTrtg  *  font 
trademark  deg: 
trademark  rad: 
pi  3  a  14150  2653089; 
public  type  degrees  =  deg  k  real; 
public  type  radians  =  rad  k  real: 
public  const  right-angle  =  90  qua  degrees: 
public  nassc  proc  Sin  (Theta:  degrees)  =  Sin  (Theta); 
public  accrue  proc  Sin  (Theta:  radians)  3  Sin  (Theta  *  pi/ 180); 
public  psuc  (name  Thetal:  radians)  :=  (Theta2:  degrees)  Is 
Thetal  :*  (Theta2  *  pi/ 180)  qua  rad: 

piddle  proc  (name  Thetal:  degrees)  ;*  (Thetal:  radians)  Is 
Thetal :■  (Theta2  *  180/pi)  qua  deg: 

end 

public  prue  (Thetal:  degrees)  +  (Thata2:  degrees)  3 

((Thetal  +  Theta2)  \  360)  qua  dag; 


Figure  IBl  Implementing  Units  with  Trademarks 
These  declarations  allow  the  use  of  angles  measured  in  either  radians  or  degress. 

father,  they  ensure  that  the  appropriate  Sin  routine  la  used  for  each  unit. 


The  main  purpose  of  a  trademark  is  the  protection  of  the  user  of  a  value  or  objeot. 


This  Is  accomplished  by  unforgeably  identifying  the  source  of  a  value  or  object,  to  its 
potential  users  (which  users  may  include  the  object's  or  value's  creators).  A  related 
construct  is  Use  seal,  which  can  loosely  be  deecrtbed  as  a  trademarked  box  [Morrls73], 
That  is.  the  object's  or  value's  originator  is  unambiguously  identified  as  with  a  trade- 
marie.  but  all  other  attributes  of  the  value  or  object  are  hidden  outside  of  the  form  in 
which  it  is  declared.  That  is.  the  object  or  value  appears  atomic  outside  the  form  in 
which  the  seal  is  declared.  Inside  this  form  the  seal  acts  just  like  a  trademark,  ..a.,  all 
the  attributes  are  visible.  For  example,  the  form  in  Figure  16  provides  a  collection  of 
procedures  for  creating  manipulating  'particle'  values.  Outside  the  form,  'parti¬ 
cles*  are  atomic. 


Particle  .Lib  a  farm 
seel  particle; 
part  =  record 
spin:  {+1. 
charge:  j-3  to  3{; 
strangeness:  j+1.  0,  -ij; 
charm:  (-1,  0,  +lj; 


public  u-quark  =  part  (•+■1.  +2,  0,  0)  qua  particle; 

public  d-quark  =  part  (-1.  -2.  0.  0)  qua  particle; 

public  a_quark  =  part  (-*-1,  -1,  +1,  0)  qua  particle; 

public  a_quark  -  part  (-r  1,  +2,  0,  *1)  qua  particle; 

public  proc  charge  (p:  particle  k  part)  ->  real  a  p.charge/3; 

public  proton,  a  part  (-*-1.  +3.  0,  0)  qua  particle; 

public  proc  (p:  particle  k  part)  +  (q;  particle  It  part) 
a  part  (p.spin  +  q.spin. 
p. charge  +  q.charge 
p. strangeness  +  q.strangeness, 
p. charm  +  q. charm)  qua  particle; 


Figure  lft.  Example  of  Seals 
It  will  than  be  possible  to  write  statements  such  as: 

with  Particle-Lib  do 


If  proton  *  u-quark  +  a  quark  +  d-quark  than  ... 


the  quantum  numbers'  (such  as  spin  and  charge)  are  hidden  outside  the  form  except 


where  explicitly  made  available  (aa  la  done  with  charge,  above). 


In  summary,  it  can  be  seen  that  seals  provide  another  Level  of  security  beyond 
trademarks.  Seals,  like  trademarks,  guarantee  that  only  the  owner  of  the  seal  can 
create  the  sealed  objects  or  values.  Seals  enforce  the  further  restriction  that  only  the 
owner  of  the  seal  can  inspect  the  attributes  of  the  sealed  objects  or  values. 


The  prototype  language  distinguishes  between  the  scope  of  a  variable  and  the  visibil¬ 
ity  of  a  variable.  The  scope  of  a  binding  is  determined  by  the  type  of  the  binding  and 
the  static  nesting  of  program  components.  Generally,  a  binding  can  be  seen  only 
within  its  scope,  although  there  are  circumstances  in  which  it  is  visible  outside  its 
scope.  For  instance,  the  with  construct  provides  access  to  the  publics  of  a  form:  in 
ocher  words,  with  makes  the  publics  visible  throughout  the  body  of  the  with. 


The  environment  in  which  a  binding  is  made  is  defined  to  be  the  otuner  of  that  bind¬ 
ing.  and  any  object  or  value  created  in  that  environment  is  likewise  owned  by  that 
environment  The  owner  of  bindings,  objects  and  values  has  special  privileges  not  pos¬ 
sessed  by  other  environments  to  which  the  names,  values  and  objects  may  be  visible. 
These  special  privileges  are.  however,  inherited  by  any  environments  in  the  scope  of 
the  bindings.  ) 

The  above  named  privileges  binge  around  the  ability  to  see  the  private  bindings  of  a 
form  In  particular,  in  the  scope  of  a  form  creation  the  private  bindings  will  be  accessi¬ 
ble  just  Uke  the  publics.  This  1s  especially  important  to  the  extension  operation,  since 
an  extension  to  a  form  will  'see'  the  private  bindings  of  that  form  only  if  the  extension 
is  made  in  the  environment  of  the  form’s  creation.  An  example  may  clarify  these 
ideas.  Recall  the  definition  of  ’seq_mstaek’  (sequence-based  message  stacks)  in  sec¬ 
tion  5.  Assume  that  this  is  a  public  binding  in  some  form  F.  Further,  assume  that 
someone  not  in  environment  F  wants  to  extend  seq_ms tacks  with  a  new  operation, 
pushed.'  such  that 


S.puahall  [XI.  X2.  ...  Xn] 


will  push  ail  of  XI.  X2,  ....  Xa  onto  S.  Tha  with  construct  must  be  used  to  make  the 
name  seq_mstack  visible.  The  form  denotation  is  then  used  to  perform  the  extension. 
Note,  however,  that  since  only  the  publics  are  visible  in  the  extension,  only  they  can  be 
used  to  implemement  ‘puahall’  (Figure  17). 

vtthP  do 

let  proc  multLaaqjaastack  = 
obf  form  seq-m  stack  with 

public  proc  pushall  (ms:  message  sequence)  is 
form  in  ms  repeat 
push  m; 

endfor 
end.  pushall: 
end  form; 

and  with: 

Figure  17.  Extending  a  Form 

If.  however,  the  extension  were  made  in  the  owning  emarv.nment ,  F,  then  the  private 
bindings  of  the  sequnstack  would  be  available,  thus  permitting  a  simpler  implementa¬ 
tion: 

proc  multi-seq.  ms  tack  = 
obf  form  seq_mstack  with 

public  proc  pushall  (ms:  message  sequence)  is 
St  :=  St  +  ms: 
end  pushall: 
end  form; 

In  this  case  pushall  is  implemented  by  directly  manipulating  the  private  data- 
structure,  St 
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